Technotools/Technotools (Chestnut CD-ROM)(1993).ISO/lang_pas/mtask11/mtask.prt

Text File | 1988-11-12 | 19KB | 854 lines

MTASK 1.1 by Wayne Conrad










                                MTASK


MTASK is a unit for Turbo Pascal 5.0, to allow a Turbo Pascal program to
exhibit simple multi-tasking.  MTASK gives your program a
non-preemptive, request driven multi-tasking capability.  I will explain
what I mean by that later.

MTASK was written and donated to the public domain by Wayne E. Conrad
(me) in November of 1988.  I may be contact via my BBS,

     Pascalaholics Anonymous
     [phone]
     300/1200/2400 bps
     24 hours/day

or by mail at my home:

     2627 North 51st Ave, #219
     Phoenix, AZ  85035

I am interested in any modifications, bug reports, or comments you have.

If you modify this package, please keep my name and the name of any
other programmers who've worked on it intact.  Please distribute the
complete ARC file, with documentation and demonstration programs
included.






















                                 -1-





MTASK 1.1 by Wayne Conrad



1.1 INTRODUCTION


MTASK allows your Turbo Pascal program to do simple multi-tasking.  I
call MTASK's brand of multi-tasking "non-preemptive, request driven."

Preemptive is a fairly common phrase, meaning that the switch from one
task to another can happen at almost any time.  Most preemptive systems
have an interrupt driver hooked to a hardware timer, which causes a task
switch every time the hardware timer goes off.  The advantage of this
kind of multi-tasking is that your programs don't have to be written
with multi-tasking in mind, and don't even have to know that its taking
place.  Also, no program can hog the system for long, because the
interrupt driver switches from one program to another fairly often.
Desqview and Double-DOS are programs that do preemptive,
interrupt-driven multi-tasking.  The disadvantage of this kind of
multi-tasking is that it can be complex to write and difficult in the
extreme to debug.  These difficulties are compounded in an MS-DOS
environment because MS-DOS was not meant to be used in a multi-tasking
environment.

On the other hand, non-preemptive multi-tasking only switches tasks at
certain, well defined times.  There is no interrupt driver that forces
task switches.  In the original Macintosh operating system, for example,
task switches only occured when a task called the operating system.  The
advantage of non-preemptive multi-tasking is that it is much simpler to
write and debug than preemptive multi-tasking, because the system has
total control of when task-switches occur.  The disadvantage to this
form of multi-tasking is that a task must request a task switch often if
the other tasks are to receive their chance to execute.  If a task does
not request a task switch for a long time, the other tasks will appear
to pause.  What's worse, if a task crashes, it won't be able to call the
operating system to let the other tasks execute, so they'll all be hung
too.

MTASK implements a very simple method of non-preemptive multi-tasking
that I call "request driven."  Request driven means that task switches
occur only when the current task calls MTASK and requests a switch.
(The sole exception is that a task switch occurs when the current task
terminates itself).  This is about the simplest form of multi-tasking
that I can envision.  It is so simple that the entire MTASK unit
compiles to only about 1400 bytes with stack checking and range checking
turned off, or less if you don't use all of its procedures.  This
simplicity also made MTASK easy to write and debug.  MTASK was written
and debugged in one day!



1.2 WHAT ARE MTASK'S LIMITS?


MTASK allows your program to set up multiple tasks within itself.  These
tasks will execute concurrently.  However, it does not effect anything



                                 -2-





MTASK 1.1 by Wayne Conrad



outside of your program.  It does not allow you to run multiple
programs, multiple copies of COMMAND.COM, or anything else like that.
It simply allows your program to do several things concurrently without
stumbling over itself.

As far as DOS is concerned, your program using MTASK is still just a
simple program.  All of the gymnastics to keep track of multiple tasks
are done by MTASK, withing your program, without the knowledge or
consent of DOS or anything else outside of your program.  Because MTASK
is so simple, it will coexist fine with any "real" multi-tasking DOS you
have set up, such as DesqView or Double-DOS.  Whenever the DOS gives
your program some time, your program will dole out that time to its
tasks.

Your program must continue to execute for its tasks to execute.  If any
task in your program exits to DOS for any reason, including a run-time
error, all tasks stop executing.  If one of your tasks shells out by
using Turbo's Exec function, then the other tasks in your program are
suspended until control returns from the Exec function to your program.

MTASK must not be made into an overlay.  Any of the tasks it controls
may be overlays, although that may be unwise.  You could end up loading
an overlay from disk during each task switch!

































                                 -3-





MTASK 1.1 by Wayne Conrad



2.1 SUMMARY OF PROCEDURES AND FUNCTIONS


To use MTASK, include it in your program's USES statements.  MTASK will
initialize itself automatically, making your main program task #1.  Your
program can then use the following procedures and functions to create
and control tasks:


     create_task         Create another task

     terminate_task      Destroy a task

     switch_task         Switch to another task

     current_task_id     Return the task ID of the current task

     number_of_tasks     Return the current number of tasks

     get_task_info       Get information about all tasks




































                                 -4-





MTASK 1.1 by Wayne Conrad



2.1.1 PROCEDURE CREATE_TASK


PROCEDURE create_task
  (
  task      : task_proc;
  VAR param ;
  stack_size: Word;
  VAR id    : Word;
  VAR result: Word
  );


     TASK is the procedure to make into a task.  It must match type
     task_proc, having a single variable as its parameter.

     PARAM is the parameter to pass to new_task.  It may be a variable of any
     type, so long its what the task expects.  For example, if you pass a
     Word and the task expects a LongInt, the task will get invalid data.

     STACK_SIZE is the size of the new task's stack.  A stack will be
     allocated from the heap.  The minimum stack size is 512 bytes, because
     Turbo's stack-check procedure flags a "stack overflow" error if less
     than 512 bytes of stack remain.

     ID is set to the task ID of the newly created task.  If the task is not
     created because of an error, then id is not set.

     RESULT is the result code, which is set to one of these values:


          0                   No error, task created ok
          heap_full           Unable to allocate heap for the task's
                              stack
          too_many_tasks      Maximum number of tasks are already
                              running


The new task is created and added to the end of the task list.  The new
task will be executed when the task before it calls switch_task.
















                                 -5-





MTASK 1.1 by Wayne Conrad



2.1.2 PROCEDURE TERMINATE_TASK


PROCEDURE terminate_task (id: Word; VAR result: Word);


     ID is the task id of the task you want to terminate.  If ID = 0,
     then the current task will be terminated.

     RESULT is the result code, which is set to one of these values.

          0                   No error, task deleted ok
          invalid_task_id     There is no task with that ID number


The designated task will be removed from the task list.  If its stack
was allocated from the heap, it is returned to the heap.

If the terminated task is the current task and there is another task in
the task list, a task switch occurs.  On the other hand, if the
terminated task is the current task and there are no other tasks in the
task list, then the program exits to DOS.

A task may terminate itself by returning from its main procedure.  For
example, when this task is executed, it will immediately display a
message and then terminate itself.


     PROCEDURE task (VAR param);
     BEGIN
       Writeln ('We just started, but already we're terminating');
     END;
























                                 -6-





MTASK 1.1 by Wayne Conrad



2.1.3 PROCEDURE switch_task


     PROCEDURE switch_task;


This procedure causes an immediate switch to the next task in the task
list.  The task list is always scanned as a circular list.  For
example, if there are three tasks in the list -- task 1, task 2, and
task 3 -- then they will be executed in this order:


     1, 2, 3, 1, 2, 3, 1, 2, 3 . . .


If the current task is the only task, then no task switch occurs.

The stack pointer is switched to its position in the new task's stack.
If the new task has just been created, then its main procedure will be
executed from the beginning.  On the other hand, if the new task had put
itself to sleep by asking for a task switch, then control will return to
the point where it called switch_task.



2.1.4 FUNCTION CURRENT_TASK_ID


     FUNCTION current_task_id: task_id;


This function returns the task ID number of the currently executing
task.  When calling an MTASK procedure to do something to a task, the
task ID number is always used to identify the task.

A task is assigned its ID number when it is created.  A task's ID number
belongs to it as long as that task exists, and will not be changed or
reassigned until the task terminates.



2.1.5 FUNCTION NUMBER_OF_TASKS


     FUNCTION number_of_tasks: task_number;


This function returns the number of tasks in the task list.  There will
always be at least one task.







                                 -7-





MTASK 1.1 by Wayne Conrad



2.1APROCEDURE get_task_info


     PROCEDURE get_task_info
       (
       VAR info: task_info_array;
       VAR n   : task_number
       );


INFO is an array of task information.  You receive a copy of the actual
task information array, not the original.  See MTASK8S for the
definition and description of task_info_array.

I really don't expect that I'll ever use this procedure, but it's there
if your program ever needs to know what the current state of MTASK is.








































                                 -8-





MTASK 1.1 by Wayne Conrad



3.1 TRICKS AND TRAPS


This section focuses on some of the tricks and traps of programming in
this multi-tasking environment.  Like all multi-tasking environments,
strange things can happen.  You'll learn how to watch for problems with
shared data, and crunched parameters.

I will only give a few examples of the problems that can occur in
multi-tasking environments.  There are other problems that can occur
when using MTASK, and many more problems that can occur when using a
preemptive multi-tasker such as UNIX.  This section should help you to
begin thinking like a real-time programmer, giving you an idea of the
kinds of problems to watch for.  For a real education on concurrent
programming, head to your library or book store and look for a book on
operating systems.



3.1.1 PASSING PARAMETERS TO TASKS


When you create a task, you can pass a parameter to it.  For example, a
BBS program needs to tell a task which node it is, so that the task
knows which serial port to use for i/o.  The parameter you pass is
"untyped," meaning that it can be any type of variable.  You must be
familiar with how Turbo handles untyped variables.

The sample program TEST19S shows how to pass a word variable to a
task.  You can pass any kind of variable, including records, arrays, and
even files.

One thing to remember is that when you pass an untyped parameter to a
task, you are actually passing the address of the parameter, not the
parameter itself.  Therefore, if you pass the task a paramater and then
modify the parameter, the task may see the new value instead of the old
value.  It will all depend upon where task switches occur.

As a general rule, parameters you pass to a task should be global
variables or typed constants.  Global variables and typed constants are
both in the data segment.  Local variables are declared on the current
task's stack, and cannot be assured of existing for very long.  If you
a procedure passes one of its local variables to a task that it's
creating, and then the procedure returns, that local variable is "thrown
away" and its space can be reused by other procedures.  That would cause
the value of the parameter you passed to the task to change
unpredictably.









                                 -9-





MTASK 1.1 by Wayne Conrad



3.1.2 SHARED DATA


Problems can occur when two or more tasks are using the same global
variables.  If two or more tasks have access to the same variable, you
need to consider carefully what will happen if two tasks access the
variable concurrently.  This pseudo-code example shows two tasks.
task_a is computing the sum of an array of Reals.  Task_b is clearing
the values in the array.



     CONST
       data_size = 1000;
     VAR
       data: ARRAY [1.11/12/88ta_size] OF Real;


     PROCEDURE task_a;
        .
        .
        .
     sum := 0.0;
     FOR i := 1 TO data_size DO
       BEGIN
       sum := sum + data [i];
       switch_task;
       END;
        .
        .
        .
     END;


     PROCEDURE task_b;
        .
        .
        .
     FOR i := data_size DOWNTO 1 DO
       BEGIN
       data [i] := 0.0;
       switch_task;
       END;
        .
        .
        .
     END;


Do you see what happens if task_a is computing the average at the same
time task_b is clearing the array?  The average will end up being
incorrect, because the data being averaged is being changed while the
average is being computed.  Obviously, this example is contrived.



                                 -10-





MTASK 1.1 by Wayne Conrad



Nobody in their right mind would call switch_task inside those
loops.  That causes many more context switches than are necessary.

One way to avoid the problem in this particular example is not to call
switch_task inside either of the loops.  Then you could be sure that an
average would not take place while you were clearing the array, and
array clearing would not take place during an average.

You cannot always avoid calling switch_task, however.  Suppose that
floating point addition on your computer was so slow that it took many
seconds to compute the average.  You may have other tasks that cannot
afford to be denied CPU time for more than a fraction of a second.  What
do you do?

The solution here is to create a flag that indicates when a task is
using the data array.  When one task is using the data array the flag
will be set to True, indicating that no other task should access it.


     CONST
       flag: Boolean = False;


     PROCEDURE task_a;
        .
        .
        .
     WHILE flag DO
       switch_task;
     flag := True;
     sum := 0.0;
     FOR i := 1 TO data_size DO
       BEGIN
       sum := sum + data [i];
       switch_task;
       END;
     flag := False;
        .
        .
        .
     END;















                                 -11-





MTASK 1.1 by Wayne Conrad



     PROCEDURE task_b;
        .
        .
        .
     WHILE flag DO
       switch_task;
     flag := True;
     FOR i := data_size DOWNTO 1 DO
       BEGIN
       data [i] := 0.0;
       switch_task;
       END;
     flag := True;
        .
        .
        .
     END;


Do you see what's going on here?  Before task_a does an average, it
checks the flag to see whether someone else is messing with the data
array.  If someone is, then it waits until the data structure is
available, sets the flag to indicate that it now "owns" the data array,
and proceeds to compute the average.  When the average is finished,
task_a resets the flag, to allow any other task which is waiting for the
data array to have access.  task_b is doing exactly the same thing.

Now both tasks can go on calling switch_task even while messing with the
data array, without concern that some other task will access the data
array at the same time.  This technique will work for any number of
tasks.



3.1.3 WHEN TO SWITCH TASKS?


Obviously, the examples in 3.1.2 switch tasks far too often.  The
program will spend more time bouncing from one task to another than it
will doing anything useful!  If your loop is too time consuming to leave
out task switches, and switching tasks during every iteration of the
loop is too often, try something like this:


     FOR i := 1 TO 10000 DO
       BEGIN
       IF i MOD 100 = 0 THEN
         switch_tasks;
       do_something_useful;
       END;


This will switch tasks every hundreth iteration of the loop.



                                 -12-





MTASK 1.1 by Wayne Conrad



If your program is going to do something that takes a while, like disk
i/o, it should probably switch tasks before doing so to let the other
tasks get some time before the long delay occurs.  In fact, if you are
doing several lengthy disk operations in a row, call switch_task before
every one.


     Assign (inf, 'INPUT11/12/88T');
     switch_tasks;
     Reset (inf);
     Assign (outf, 'OUTPUT11/12/88T');
     switch_tasks;
     Rewrite (outf);


Many programs have to wait for input at some point.  Input loops are a
perfect place to switch tasks.  In fact, any time a task cannot proceed
because its input is not ready, or for any other reason, it should
switch tasks.


     WHILE NOT KeyPressed DO
       switch_tasks;
     ch := ReadKey;


It is a matter of judgement where task switches should occur.  It will
depend upon the program and circumstances around each operation.



4.1 REVISION HISTORY


Version 1.0, MTASK10.ARC.  Original release by Wayne E. Conrad

Version 1.1, MTASK11.ARC.  Minor changes to documentation, including
using spaces instead of tabs.  ARC file now includes the original
documentation in Multi-Edit format, as well as the printable file.














                                 -13-